[レポート]DAT302: ElastiCache Deep Dive：インメモリデータストアのデザインパターン #reinvent

こんにちは、坂巻です。

本記事はAWS re:Invent 2018のセッション「ElastiCache Deep Dive: Design Patterns for In-Memory Data Stores」のレポートです。

概要

In this session, we provide a behind the scenes peek to learn about the design and architecture of Amazon ElastiCache. See common design patterns with our Redis and Memcached offerings and how customers use them for in-memory data processing to reduce latency and improve application throughput. We review ElastiCache best practices, design patterns, and anti-patterns.

スピーカー

スピーカーは以下です。

• Michael Labib - Principal Solutions Architect, AWS

レポート

アジェンダ

• What's New
• Amazon ElastiCache Deep Dive
• Redis Common Architecture Patterns
• Caching Strategies
• Best Practices

What's New: Redis & Memcached

Redis 5.0

• Redis Streams
• SortedSets now have LIST capabilities
• HyperLogLogs has an optimezed algorithm
• Speed Improvements
• More at https://aws.amazon.com/jp/redis/Whats_New_Redis5/

Memcached 1.5.10

• Automated Slab rebalancing
• LRU crawler to background-reclaim memory
• Faster hash table lookups with mumur3 algorithm

新しいインプレースバージョンのアップグレード

• Redis Clusterを最新のエンジンバージョンにインプレースアップグレードする
• 手動の手順やアプリケーションの変更不要
• ElastiCache gor Redisバージョン3.2以上で利用可能

新しいAmazon ElastiCache最適化インスタンスM5 | R5

• メモリ容量9.5TiBまで拡張可能
• ハードウェアと軽量の専用ハイパーバイザーであるAWS Nitro Systemは、ベアメタルと区別できないパフォーマンスを実現
• 最大3.1 GHzのカスタムIntel XeonスケーラブルプロセッサーおよびAVX-512

新しいAmazon ElastiCache 250ノードサポート

9.5TiBでないとき！

• 例
  • Assume 125 shards made of 1 primary + 1 Replica = 250 nodes
  • Assume R5.24xlarge(635.61GiB)
  • Cluster memory 635.61GiB * 125 = ~80TiB = ~88TB

近日公開

• マルチコアノードの性能向上
  • 大幅なスループット向上をもたらすさらなる最適化
• 名前変更コマンドのサポート
  • コマンドの名前を変更する機能
• セルフサービスのパッチ適用
  • 更新が発生したときを制御するための柔軟性を向上

Amazon ElastiCache Deep Dive

Redisの概要

• 高速
  • ほとんどのコマンドで1ms未満の遅延
  • オープンソース
  • 簡単に学べる
• 高可用性
  • レプリケーション
• 原子操作
  • トランザクションをサポート
• メモリ内Key-Valueストア
• パワフル 〜200コマンド、Luaスクリプトジオスペース、Pub / Sub
• Variosデータ構造
  • 文字列、リスト、ハッシュ、セット、ソートセット、ビットマップ、ストリーム、HyperLogLog
  • 復元する
  • スナップショットを有効にする

Redis管理の課題

• 管理が難しい
  • ハードウェアのプロビジョニング、ソフトウェアのパッチ適用、セットアップ、構成、およびバックアップの管理
• 高水準にするのは難しい
  • アプリケーションのパフォーマンスに影響するRedisの停止
• スケールが難しい
  • オンラインスケーリングがエラーを起こす可能性がある。複製のパフォーマンスを監視する必要があります
• 高価
  • 人、プロセス、ハードウェア、ソフトウェアに投資する

RedisのためのAmazon ElastiCacheの紹介

• 極限性能
  • ミリ秒未満の応答時間のためのメモリ内データストアおよびキャッシュ
• 信頼性
  • Muliti-AZ
  • 詳細監視
  • 自動フェイルオーバー
• フルマネージド
  • AWSはすべてのハードウェアとソフトウェアの設定、構成、監視を管理
• セキュア＆コンプライアンス
  • Amazon VPC
  • HIPAA、PCI、FedRAMP
  • 安心して輸送中の暗号化
  • 認証
• エイシリースケーラブル
  • レプリカによるスケーリングの読み取り
  • 書き込みとメモリ
  • シャーディングによるスケーリング
  • 無停止スケーリング
• レディス対応
  • Redis 5のサポート
  • Redisクライアント互換

Redis use cases

• キャッシング
• セッションストア
• リアルタイム解析
• チャットアプリ
• ゲームのリーダーボード
• メッセージキュー
• 地理空間
• 機械学習
• メディアストリーミング

ElastiCache customers

Redis Common Architecture Patterns

Caching

Real-time: Sentiment analysis

Real-time: AWS IoT Core

Real-time: Amazon Kinesis filerng

Mobile

Graph & search integration

ベストプラクティス

クラスタサイジングのベストプラクティス

ストレージ - クラスタには十分なメモリが必要

• 推奨：必要なメモリ+ 25％ 予約メモリ（Redisの場合）+成長のための余裕（オプションの10％）
• 排除ポリシーとTTLを使用して最適化する
• CloudWatchアラームを使用してmax-memoryに達する前にスケールアップまたはスケールアウト
• 費用対効果のためにメモリ最適化ノードを使用する（RSサポート）

パフォーマンス - パフォーマンスは損なわれるべきではありません

• Redisベンチマークツールを使用したベンチマーク操作
  • READIOSPSの追加 - レプリカの追加
  • WRITEIOPSを追加するには - 分割を追加する（スケールアウト）
  • ネットワークIOを増やす - ネットワーク最適化されたインスタンスを使用してスケールアウトする
• 一括読み取り/書き込みにパイプラインを使用する
• データ構造コマンドのビッグ（O）時間の複雑さを考慮する

クラスタ隔離（アプリ共有キースペース） - ークロードに適した戦略を選択する

• ワークロードと環境に基づいて、どのような分離が必要かを特定する

CloudWatchの監視

• 指標：BytesUsedForCache
  • 解決方法：スケールアップ（アウト）
• メトリック：CacheHits / Metric：CacheMisses
  • ヒット/ミス率80％を目指す
  • 解決方法：TTLとキャッシュ戦略を最適化する
• 指標：CurrConnections
  • 安定していなければならない
  • 解決方法：接続プーリング、スケールアウト
• 指標：EnginCPUUtilization
  • 90％の割り当てを超えてはならない
  • 解決方法：スケールアップ（アウト）
• 指標：Eviction> 1
  • 解決方法：スケールアップ（アウト）
• メトリック：SwapUsage>数MB
  • 解決方法：スケールアップ（アウト）

さいごに

ElastiCacheについてのベストプラクティスや、CloudWatchメトリクスの具体的な値まで把握することができたセッションでした。